EXPRESS MAIL NO. EV335515937US 

PROVIDING A MARKETPLACE FOR WEB SERVICES 
TECHNICAL FIELD 

[0001] The following disclosure relates generally to facilitating interactions 

between computing systems, and more particularly to facilitating such interactions 
by acting as an intermediary, such as an electronic marketplace via which Web 
service providers make their Web services available and via which Web service 
consumers locate, purchase access to, and access those Web services in 
accordance with prices and use conditions specified for those Web services. 

BACKGROUND 

[0002] Various mechanisms exist to allow computers and executing software 

applications to interact. For example, remote procedure call ("RPC") protocols 
have long existed that allow a program on one computer to cause a program on 
another computer to be executed, and various object-oriented architectures such 
as CORBA ("Common Object Request Broker Architecture") and DOOM 
("Distributed Component Object Model") provide similar capabilities. In addition, 
a variety of middleware programs have been implemented to connect separate 
applications (often of distinct types and from unrelated sources) to allow 
communication. For example, various EDI ("Electronic Data Interchange") 
networks exist that provide standard mechanisms to allow a computer system of 
one user of the network to send data to a computer system of another user of the 
network. 

[0003] The widespread popularity of the World Wide Web ("Web") has provided 

additional opportunities for computers to inter-communicate. For example, much 
current Web use involves users interactively requesting Web pages from Web 
servers (e.g., via executing Web browser applications of the users) and receiving 
the requested information in response. In addition to such interactive user 
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specification of requested information, there is also growing use of the Web to 
support the programmatic interaction of remote applications to exchange 
information via defined APIs ("application program interfaces"), referred to as 
Web services. 

[0004] Web services allow heterogeneous applications and computers to interact, 

and can be defined and implemented using a variety of underlying protocols and 
techniques. For example, some Web service implementations return data in XML 
("extensible Markup Language") format using HTTP ("HyperText Transport 
Protocol") in response to a Web service invocation request specified as a URI 
("Uniform Resource Identifier"*), such as a URL ("Uniform Resource Locator") that 
includes a specified operation and one or more query parameters. In other 
implementations, additional underlying protocols are used for various purposes, 
such as SOAP ("Simple Object Access Protocol") for standard message 
exchange, WSDL ("Web Services Description Language") for description of 
service invocations, and UDDI ("Universal Description, Discovery, and Integration 
service") for discovery of available services. 

[0005] Although Web services allow various applications and computers to 

interact, the current implementations and uses of Web services have various 
problems. For example, current Web service implementations are typically 
designed with only a very limited number of predefined applications interacting, 
and do not typically address a variety of issues for wide-scale interaction of 
providers and potential consumers of Web services. In addition, current Web 
service implementations do not typically provide effective means for potential 
consumers to discover or locate Web services that are desired or that may be of 
interest, such as via current UDDI-based implementations that may identify a 
connection point for one or more Web services but that do not typically provide 
any of a variety of other types of information related to the Web services to assist 
potential consumers (e.g., indications of usage by others, such as a ranking 
relative to other Web services; indications of comments and/or reviews by others; 
information related to the past provision of the Web service and/or the provider of 
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the Web service, such as average up-time and response time; etc.). Current 
Web service implementations also do not typically provide sufficient assurance to 
potential consumers that prospective providers of Web services will reliably and 
accurately provide desired Web services, do not typically provide sufficient 
security for providers of Web services to ensure that their Web services will be 
made available only to authorized consumers and only in accordance with any 
conditions specified by the providers, do not typically provide easy-to-use 
mechanisms to allow Web service providers to collect specified payment for the 
use of their Web services by consumers, do not typically allow Web service 
providers to manage and monitor the use of their Web services, do not typically 
allow Web service consumers to monitor the use of provided Web services on 
their behalf, etc. 

[0006] Thus, it would be beneficial to provide a solution that addresses these and 

other problems associated with the use of Web services and/or that otherwise 
facilitates the interaction of computer systems and executing applications. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0007] Figures 1A-1D illustrate examples of a user interface for Web service 

provider users and Web service consumer users to interact with an embodiment 

of a Web Services Marketplace ("WSM") system. 
[0008] Figure 2 is a network diagram illustrating components and information flow 

of an example embodiment of the WSM system. 
[0009] Figure 3 is a block diagram illustrating an embodiment of a computing 

system suitable for executing an embodiment of the WSM system. 
[0010] Figure 4 is a flow diagram of an embodiment of the WS Registration 

routine. 

[0011] Figure 5 is a flow diagram of an embodiment of the WS Subscription 

routine. 

[0012] Figure 6 is a flow diagram of an embodiment of a WS Invocation routine. 

[0013] Figure 7 is a flow diagram of the WSM Portal routine. 
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DETAILED DESCRIPTION 



[0014] A software facility is described that facilitates interactions between 

computing systems, such as by in some embodiments providing an electronic 
Web service ("WS") marketplace via which third-party WS providers, make their 
WSes available to third-party WS consumers who locate and purchase access to 
those WSes via the electronic marketplace. 

[0015] In some embodiments, the WS marketplace ("WSM") allows third-party WS 

providers to register their WSes with the electronic marketplace so as to make 
those WSes available to some or all WSM users who are potential consumers of 
the WSes. In particular, in some embodiments, a WS provider may specify 
pricing information for the use of their WS and/or other WS use conditions at the 
time of WS registration. The WS providers also specify the manner(s) in which 
their WSes are to be invoked, as well as various description information about 
their WSes that may be provided to potential consumers to assist in their 
determination of whether to use the WS. Once WSes have been registered at the 
WSM, they can be made available to potential WS consumers in various ways, as 
discussed in greater detail below. In some embodiments, a WS provider may also 
need to first register with the WSM as a user before registering their WSes (e.g., 
to provide contact information, information on how payments to the WS provider 
are to be made, etc.). 

[0016] As discussed in greater detail below, various types of use prices for using 

WSes can be specified, such as on a per-use basis, for a subscription that is valid 
for a specified length of time and/or number of uses, etc. Various non-price use 
conditions can similarly be specified in some embodiments, such as restrictions 
on types of consumers allowed to use the WS, restrictions on types of uses 
allowed for the WS and/or for any information provided by its use, restrictions on 
how frequently the WS can be used by a particular consumer or by all consumers, 
etc. In particular, in some embodiments each WS provider can specify one or 
more use prices for each WS that they register, and the WSM then sets one or 
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more consumer access prices for those WSes that are each based on one or 
more of the specified use prices (e.g., access prices that are the same as the use 
prices, or instead that include additional fees charged by the WSM or a reduction 
in fees provided by the WSM). 

[0017] After a potential WS consumer has identified a registered WS of interest, 

the potential WS consumer can interact with the WSM to obtain access to that 
WS, such as by providing an access fee payment based on an access price (if 
any) for the WS and by satisfying any other specified use conditions for the WS. 
In some embodiments, some or all consumers obtain access to registered WSes 
by purchasing subscriptions to those WSes for later use, and in some 
embodiments non-subscription use of registered WSes is provided. For example, 
one-time or limited non-subscription uses of a WS may be provided for a variety 
of reasons, such as to allow an evaluation or test use of a WS in order to 
determine whether to purchase additional uses, for use of registered WSes that 
are free, to allow anonymous access without a defined subscription, etc. As 
discussed in greater detail below, various types of subscriptions can be provided 
in various embodiments, including one-time use subscriptions, subscriptions for a 
specified length of time and/or number of uses, etc. In addition, in some 
embodiments a WS consumer may need to first register with the WSM as a user 
before obtaining access to registered WSes (e.g., to provide contact information, 
payment source information, formatting and protocol preferences for WS 
invocation response information, etc.). 

[0018] When a consumer's access to a WS is authorized by the WSM but not 

provided immediately (e.g., by purchasing a subscription), the consumer will in 
some embodiments receive authorization information for use with later requests 
for the authorized access (e.g., a unique subscription ID for a purchased 
subscription, or a transaction ID for later-occurring non-subscription transactions). 
If so, the later requests from the consumer to provide the authorized access may 
include providing the previously received authorization information, and may 
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further be supplied or specified in a manner indicated to the consumer at the time 
of original access authorization. 

[0019] After receiving an access request from a consumer for current use of a 

registered WS, the WSM determines whether the use of the WS by the consumer 
is authorized, such as based on any authorization information supplied with the 
request. In addition, in some embodiments the WSM may further determine at the 
time of requested WS use whether any payment obligations and specified use 
conditions are currently satisfied for an invocation of the WS. If the WSM 
determines that the WS use is authorized, the WSM interacts with the provider of 
the WS to invoke the WS and obtain any response information. The WSM then 
provides some or all of the response information to the consumer. 

[0020] In some embodiments, the WSM performs additional formatting of the 

response information before providing it to the consumer. The information 
formatting can be performed in various ways and for various purposes, such as to 
act as a translator/adapter that accommodates previously specified preferences of 
the WS consumer (e.g., information format and/or protocol preferences requested 
from the WS consumer when they previously registered with the WSM), to 
combine the response information with other information {e.g., response 
information from other invoked WSes), and to obfuscate information related to the 
invocation of the WS (e.g., the specific invocation request, information about the 
WS provider, information about the time of invocation of the WS, etc.). 

[0021] In addition, in some embodiments the WSM may maintain one or more 

caches or other storage mechanisms to store response information from WS 
invocations, and if so may in some situations provide such stored response 
information to consumers rather than invoking the WSes to obtain additional 
response information (e.g., when the stored data was recently received and is of a 
type that is not time-sensitive and/or subject to rapid change) - such response 
information may in some embodiments include not only information provided by 
the WS as the product of the invocation, but also status or other response 
messages (e.g., for a WS that does not otherwise provide information in response 
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to its invocation) or instead an indication that the WS does not provide any 
response. Such caching may provide benefits to both WS consumers (e.g., by 
providing response information even if a WS provider is not currently available, by 
providing response information more rapidly than if the WS was dynamically 
invoked, etc.) and to WS providers (e.g., by providing to WS consumers a service 
invocation volume higher than the WS provider can actually handle, by providing 
service to WS consumers even if the WS provider has temporarily throttled some 
or all requests to its WS, etc.). 

[0022] As previously noted, potential WS consumers can identify WSes of interest 

in a variety of ways. In some embodiments, the WSM allows potential WS 
consumers to search the registered WSes in various ways, such as based on the 
type of service and/or type of data provided, on the use price, on the WS provider, 
on the WS description, etc. In addition, in some embodiments, the registered 
WSes may be categorized into groups of related WSes (e.g., in a hierarchical 
manner with one or more levels of sub-categories), and if so potential WS 
consumers may be able to browse within specified categories and sub-categories 
and/or may be able to limit their search to specified categories and sub- 
categories. Moreover, a variety of types of WS-related information may be 
provided to potential WS consumers, such as by providing lists or other 
indications of top-ranked and/or top-rated WSes, indications of recommended 
WSes (e.g., personalized to the current potential WS consumer based on 
information known about that consumer), etc. 

[0023] In addition, after identifying one or more WSes of potential interest, a 

potential WS consumer may be able to review additional information about each 
WS, such as by receiving a Web page specific to a WS that includes description 
information for the WS and that optionally includes various other information 
about the WS (e.g.. pricing information, information about the WS provider, etc.). 
In some embodiments, such WS-specific information may also include a variety of 
other types of information, including reviews of the WS by other WS consumers 
that have used the WS and/or summaries of such reviews, indications of rankings 
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and/or ratings of the WS relative to other WSes based on various criteria (e.g., 
number of uses, a recent trend in use, consumer-specified ratings, etc.), 
indications of similar WSes (e.g., based on category) and/or otherwise related 
WSes (e.g., other WSes by the same WS provider, other WSes that have been 
used by other WS consumers that have previously used this WS, etc.). 
[0024] In some embodiments, some or all of the described actions by WS 

providers and/or WS consumers are performed via user interactions with a Web 
site for the WSM, such as a Web site dedicated to providing a marketplace for 
Web services or instead a Web site of a more general Web store that provides 
various types of items (e.g., products and/or services) that include the Web 
services. Alternatively, in some embodiments, some or all interactions by the WS 
providers and/or WS consumers are instead performed by programs acting on 
behalf of the WS providers or consumers programmatically interacting with one or 
more computing systems of the WSM, such as via defined APIs (e.g., via Web 
services provided by the WSM to implement the underlying functionalities for the 
WSM) - in some embodiments, such APIs are based on the use of XML over 
HTTP (e.g., as part of the REpresentational State Transfer, or "REST", distributed 
interaction model that focuses on resources), while in other embodiments the 
APIs may be based on the use of SOAP and/or other protocols related to Web 
services. 

[0025] In some embodiments, the WSM further provides a capability for WS 

providers and/or WS consumers to monitor and manage their interactions with the 
WSM, such as via a portal. For example, a registered WS provider may in some 
embodiments monitor their registered WSes, such as to determine the current 
level and/or a historical level of the use of those WSes by WS consumers, or 
instead to determine a current status of their WSes (e.g., to verify that their WSes 
are currently operating properly). In addition, WS providers may be able to 
manage various aspects of their registered WSes, such as to modify pricing 
information and other use condition information, or to dynamically specify current 
throttling conditions for the use of their WSes (e.g., to limit volume and/or type of 
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use of the WSes for a specified period of time or until specified conditions are 
satisfied or until further notice). WS providers may also review and/or manage 
their user account information, such as to change their current contact information 
or to review payment amounts currently owed to the WS provider by the WSM. In 
a similar manner, registered WS consumers may monitor and manage their WS 
subscriptions or other WS access authorizations (e.g., to review recent use of 
their subscriptions and the amount of previously purchased or otherwise approved 
subscription use remaining, to dynamically specify current throttling or other 
restriction conditions for the use of their subscriptions, etc.), as well as review and 
manage their user account (e.g., to modify payment source information, or to 
authorize additional WS subscriptions or other WS use, such as by purchasing 
WSM-provlded "points" that can later be used to pay for or authorize WS use). 

[0026] As one example of another type of information that can be specified by WS 

providers and/or WS consumers in some embodiments (e.g., via the WSM portal 
or during registration), various types of notification requests may be specified for 
various types of information. For example, a WS provider may want to receive a 
standard email notification when the average volume of invocations of their WSes 
over a specified period of time exceeds a specified threshold, and may further 
wish to receive an urgent alert notification when one of their WSes goes offline or 
otherwise generates an error condition. Similarly, WS consumers may wish to 
receive notifications based on use or current status of their subscriptions, on the 
current availability of specified WSes and/or specified categories of WSes, on the 
current status of their user account information (e.g., the amount of WSM points 
remaining), etc. Such notification requests may include specifications of how to 
perform the notification, as well as the conditions that trigger the notification when 
they are satisfied. As the WSM operates, it monitors defined notification 
conditions in order to determine when notifications are appropriate, and performs 
the requested notifications in the manner specified. 

[0027] In addition, while a WS subscription is in some embodiments limited to the 

particular WS consumer that created the subscription, in other embodiments a 
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WS subscription may be sliared among multiple different users. For example, in 
some embodiments a WS consumer may specify one or more affiliate users for 
one or more of their WS subscriptions, with each affiliate user given specified 
rights to use those WS subscriptions (e.g., authorization to make a specified total 
number of WS invocation requests based on the subscription or a specified limit 
on the volume of such WS invocation requests, a specification of conditions under 
which use of the subscription by an affiliate is allowed or disallowed, etc.). In 
addition, in some situations a WS consumer may create a WS subscription on 
behalf of an indicated application (or a specified copy or instance of such an 
application), such as an application developed and/or distributed by the WS 
consumer, and may specify that some or all users of that application are 
authorized to use that WS subscription in some or all situations. Conversely, in 
some embodiments such an application developer or distributor may instead 
Incorporate one or more WS Invocation requests as part of their application 
(whether or not in conjunction with a subscription by that WS consumer), but may 
instead limit some or all uses of those WS invocation requests by the application 
users such that those users may instead need to provide their own payment 
and/or subscriptions to those WSes in order to use that functionality of the 
application. 

In some embodiments, composite Web services may also be registered 
with the WSM and used by WS consumers, with each composite WS able to 
invoke one or more other WSes. In addition, in some embodiments a composite 
WS may include specified logic related to how and when to invoke the other 
WSes (e.g., based on a scripting language), such as to provide conditional 
invocation of one WS based on the response information received from another 
WS. As one example, a composite WS may invoke two or more other WSes (e.g., 
WSes from WS providers unrelated to the creator of the composite WS) in order 
to obtain response information that is then aggregated to provide the response 
Information for the composite WS, while as another example some or all of the 
WSes specified for the composite WS are provided by the composite WS creator 
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and the composite WS specifies logic such that one of the specified WSes is 
invoked only if appropriate information is received from earlier invocation of 
another of the WSes (e.g., if that received Information Is to be used as part of that 
later invocation). In yet another example, a composite WS may invoke a single 
WS (e.g., from a WS provider other than the composite WS creator) in order to 
encapsulate that single WS using additional information and/or logic specified as 
part of the composite WS. In some embodiments, any third party can create and 
register composite WSes that invoke other WSes provided by other WS 
providers, while in other embodiments various restrictions may be imposed on the 
creation of such composite WSes (e.g., to limit composite WS creation to WS 
providers that provide at least one or all of the WSes that are part of the 
composite WS). In addition, in some embodiments such composite WSes can 
have their own specified pricing information and other use conditions, while in 
other embodiments such pricing and use conditions will instead be automatically 
determined based on the pricing and use conditions of the underlying WSes 
invoked by the composite WS. 
[0029] Moreover, in some embodiments various third parties can interact with the 

WSM to obtain various additional functionality for themselves and/or to provide 
such additional functionality to other users. For example, in some embodiments 
external computing systems may provide WS coordination services to other users, 
with the computing systems defining WS coordination requests and interacting 
with the WSM to request satisfaction of those requests. Such coordination 
requests may in some embodiments specify other registered WSes to be invoked 
and/or specify various logic to be executed, thus providing capabilities similar to 
those of registered composite WSes without having to register those WS 
coordinations. The coordination requests may be supplied to the WSM for 
execution (e.g., for a fee charged by the WSM, or instead based on the specified 
pricing information for the WSes Invoked by the coordination), and may be 
represented in various ways In various embodiments (e.g., as data structures, 
code modules, templates, mappings, portable code, etc.). In other embodiments. 
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such third-party coordination services may instead execute the coordination logic 
for coordinations, such as by interacting with the WSM to individually invoke 
each WS for the coordination as specified by the logic for the coordination and 
then combining any resulting response information to be provided to the requester 
of the coordination (e.g., a user of the coordination service, such as for a fee). 

[0030] In addition to coordination services, third parties can obtain and provide a 

vanety of other types of functionality by interacting with the WSM. For example, 
in some embodiments some third parties may provide WSM agents that interact 
with the WSM to provide additional functionality to users, such as to monitor 
various aspects of the operation of the WSM in order to provide information or 
notifications to the user (e.g., in situations in which the WSM does not provide 
corresponding notification capabilities for the type of information being monitored 
by the agent, or instead to replicate a capability available from the WSM for a 
user who is not eligible to receive the information from the WSM). A variety of 
other types of interactions with the WSM can similarly be provided to enable 
various other types of additional functionality and capabilities. 

[0031] As previously noted, in some embodiments some or all of the registered 

WSes may have specified pricing information such that WS consumers provide 
payment to use those WSes. In some embodiments, a variety of types of billing 
mechanisms are provided for WS consumers. For example, as previously noted, 
in some embodiments WS consumers may be able to purchase WS subscriptions 
that can then be used at later times, and in some embodiments the WSM may sell 
non-subscription WS access. In addition, in some embodiments billing 
occurrences are based on prior specified Service Level Agreements ("SLAs") with 
certain WS consumers and/or based on the Quality of Service ("QoS") requested 
by and/or actually provided to the consumer. For example, a provider of a WS 
may specify a use price for that WS that is based on one or more specified QoS 
levels provided by that WS provider in conjunction with the access to that WS 
(e.g., a maximum response time, a minimum level of accuracy of response 
information, etc.), such as the only use price for that WS or instead one of 
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multiple use prices (e.g., with one or more of the other use prices having other 
specified QoS levels and/or no QoS levels), and if so access to that WS that is 
purchased based on that use price (e.g., a subscription purchased for an access 
fee based on that use price) is performed in accordance with those specified QoS 
levels when possible. Similarly, an operator of the WSM may in some 
embodiments specify an access price for each of one or more of the registered 
WSes that is based on one or more specified QoS levels provided by the WSM in 
conjunction with access to those WSes (e.g., a maximum response time, a 
minimum level of accuracy of response information, etc.), such as the only access 
price for a WS or instead one of multiple access prices for the WS (e.g., based on 
one or more specified use prices for the WS, with one or more of the other access 
prices having other specified QoS levels provided by the WSM and/or no QoS 
levels), and if so access to that WS that is purchased based on that access price 
is performed in accordance with those specified QoS levels when possible. In 
some embodiments, if access to a WS is not provided to a consumer in 
accordance with specified QoS levels purchased by that consumer and/or is not 
provided in accordance with any previously specified SLAs for that consumer, 
various additional actions may be taken to compensate the consumer (e.g., by 
providing a payment credit, by not counting that access as part of the paid access 
for the consumer, etc.) and/or to correct any problems (e.g., to correct any internal 
mechanisms of the electronic marketplace, such as by notifying appropriate 
personnel associated with the electronic marketplace; to correct performance of 
the provider of the WS, such as by notifying appropriate personnel associated 
with the WS provider and/or by providing a financial incentive to the WS provider, 
such as by delaying or reducing payment to that WS provider; etc.). 
[0032] Moreover, in some embodiments WS consumers can obtain WSM-provided 

points that can be later used to purchase subscriptions and other WS access for 
various WSes - such points may be a WS payment option that WS consumers 
can purchase or otherwise earn (e.g., as a reward) for later use with a specified 
group of WSes and/or WS providers (e.g., all WSes and WS providers). The 
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points for a WS may be identified to a potential WS consumer in various ways in 
various embodiments (e.g., displayed or otherwise accessible as a subscription 
or access price for some or all WSes, whether in addition to or instead of one or 
more prices in governmental currencies), and the determination of how many 
points are needed to purchase access to a WS subscription or other WS access 
may similarly be determined in various ways in various embodiments (e.g., by 
specifying and using a standard exchange rate for all WSes; by allowing each WS 
and/or WS provider to have an individualized specified exchange rate, such as 
one specified at registration time for the WS and/or WS provider; or by 
dynamically determining appropriate WSM points for a WS based on a variety of 
factors when the price is provided to a potential WS consumer, such as a current 
usage rate of the WS, other current conditions such as a current day/time, 
information about the WS consumer, etc.). Similarly, in other embodiments the 
WSM may accumulate the costs of some or all of the WS uses for a consumer 
over a specified period of time, such as to provide a single monthly bill for all use 
of a specified WS or of all WSes. 
[0033] In addition, in some embodiments the WSM provides various security 

and/or privacy mechanisms to ensure that only authorized WS providers can 
register and provide WSes and/or that only authorized WS consumers can 
subscribe to and/or access registered WSes. Such security and/or privacy can be 
provided in a variety of ways, including the use of passwords, public key 
encryption, digital certificates, etc. In addition, the WSM may use various security 
and/or privacy mechanisms with respect to management/monitoring interactions 
by WS consumers and/or WS providers, such as to provide information to users 
only when they are authorized to receive it and to allow modification of WS- 
related information and of subscriptions only when authorized. Similarly, in 
embodiments in which affiliates of WS consumers or other users are allowed at 
least some access to subscriptions of the WS consumer, various security and/or 
privacy mechanisms may be employed to ensure that the affiliates are authorized 
to receive any benefits and information provided to them. 
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[0034] Furthermore, in addition to having WSes provided by third-party WS 

providers and to providing access to registered WSes for third-party WS 
consumers, in some embodiments the WSM itself may act as a WS provider 
and/or WS consumer for one or more WSes, such as an alternative to other third- 
party provided WSes or instead to provide WSes that are not othenA/ise available 
to WS consumers. In addition, various other capabilities provided and used by 
the WSM may also be implemented as WSes, such as a WSM API available to 
WS providers and/or WS consumers, as well as internal capabilities used by the 
WSM (e.g., determining whether a specific subscription request for a WS satisfies 
the specified use conditions for that WS by invoking an internal WS that provides 
the service of comparing the specified use conditions and requested use 
information to determine whether the specified use conditions are satisfied). 

[0035] In addition, as discussed in greater detail below, the WSM can also provide 

a variety of other types of functionalities and capabilities as described. 

[0036] For illustrative purposes, some embodiments of the software facility are 

described below in which a specific WSM embodiment provides various specific 
types of capabilities and functionalities with respect to various specific types of 
WSes, and uses various specific types of user interfaces and other interactions to 
provide those functionalities and capabilities. However, those skilled in the art 
will appreciate that the techniques of the invention can be used in a wide variety 
of other situations, including with services and items other than Web services, 
and that the invention is not limited to the exemplary details provided. 

[0037] Figures 1A-1D illustrate examples of a user interface provided by an 

embodiment of the WSM to assist WS provider users and WS consumer users in 
interacting with the WSM. In particular, Figure 1A illustrates a user interface 
screen that provides information 110 about various registered WSes available via 
the WSM, which in this example are displayed to a potential WS consumer as 
search results in response to a search by the WS consumer for Web services 
related to the search term "map." In other embodiments, information about 
available WSes can be provided to WS consumers in a variety of other ways. In 
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addition, in this example embodiment the WSM is part of a Web store that 
provides to consumers a variety of types of items that include registered WSes. 

[0038] In this example embodiment, various information about a number of 

available WSes 110a-110j is displayed to the potential customer, with the WSes 
divided into several WS categories 111 as shown. A variety of information is 
provided for each indicated WS, including a name 112, an indication of the WS 
provider 113 that is the source for the WS, one or more prices 114 corresponding 
to use of the WS, any specified use conditions 1 15 for the WS, and a description 
1 17 of the WS. In this example, those types of information are provided by a WS 
provider when registering a WS, and each WS further has a unique item ID 116 
that is automatically generated by the WSM, although in other embodiments such 
unique item IDs may not be used. As is shown, a variety of types of pricing 
models and use conditions are illustrated in this example. 

[0039] Figure 1 B Illustrates an example user interface screen via which a potential 

WS consumer can review information about an available WS and select to 
subscribe to the WS. In particular, the illustrated user interface includes a section 
121 that provides a summary description of a particular WS and a section 127 
that provides additional details about the WS. The user interface screen also 
includes a user-selectable control 123 via which the user can indicate to save an 
indication of the WS in a shopping cart of the user for possible later subscription. 
In addition, the user interface screen includes a section 125 via which the user 
can select to request a subscription to the WS, including a user-selectable control 
126a to make the subscription request using the current information in user- 
modifiable fields 125b and 125c. In particular, field 125b may be provided for 
WSes that have multiple associated subscription types, such as a single-use 
subscription and a monthly subscription, and the user-modifiable field 125c 
conresponds to situations in which the user has multiple predefined sources of 
payment that they can select for use. Thus, in this example, before selecting the 
control 125a, the user may select a type of subscription (e.g., with a 
corresponding subscription price) and a payment option to be used for the 
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payment. After the user selects the control 125a, the WSM determines whether 
to approve the subscription request, and if so takes appropriate steps to 
implement the subscription. 

[0040] Figure 1C illustrates an example user interface screen with which a WS 

provider can register a WS so as to make it available to consumers via the WSM. 
In particular, the example WS registration screen includes instructional 
information 131, and sections 133-137 in which the WS provider user can specify 
various types of information for the WS being registered, including a name, 
pricing information, use conditions, description, and one or more optional related 
terms {e.g., to assist in automatic categorization of the WS and/or to assist in 
identification of the WS as relevant to a potential consumer's search or other 
expression of interest about WSes). In this illustrated example, the pricing 
information section 135 allows the WS provider to specify one or more use prices 
for different types of subscriptions or other uses of the WS, although in other 
embodiments only a single type of pricing may be allowed. In addition, in some 
embodiments at least some of the registered WSes may not include some or all of 
the types of information, such as not including pricing information {e.g., for free 
WSes) or not including other types of use conditions. The illustrated WS 
registration screen also includes a user-selectable control 139 via which the WS 
provider can indicate to register the WS after appropriate information has been 
supplied. After the control has been selected, the WSM determines whether to 
approve the registration, and if so takes appropriate action to notify the WS 
provider of the acceptance and to make the registered WS available to 
consumers via the WSM. 

[0041] Figure 1 D illustrates an example user interface screen via which various 

types of information about registered WSes can be provided to potential WS 
consumers. In particular the illustrated user interface screen includes a section 
140 that provides various information about top-ranked WSes available via the 
WSM, such as to illustrate a current rank, a rating 141, indications of similar 
WSes 142, and indications of other WSes 143 that may be of interest based on 
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preferences of other users. In this example, the WS ratings are user-specified 
and the ranks are automatically calculated in one of a variety of ways (e.g., 
cumulative sales volume, recent sales volume, recent trends in sales volume, 
accuracy or other performance measure for the WS, total usage based on the 
number of access requests or other usage measure, breadth of invocations based 
on the number of different WS consumers and/or applications making the access 
requests, number of access requests per second, etc.), although ratings and/or 
rankings could be determined in other ways in other embodiments. 

[0042] The example user interface screen in Figure 1D also includes a section 

145 that provides various personalized recommendations of registered WSes to 
the current user, such as based on previously specified interests of the user 
and/or other automatic determinations of WSes of potential interest (e.g., based 
on usage history for the user). In this illustrated example, each of the 
recommended WSes 145a-145b is illustrated with various associated information, 
such as a corresponding use price and WS provider, and each additionally has an 
associated user-selectable control 146 with which the WS can be added to the 
user's shopping cart and a user-selectable control 147 with which the user can 
request to immediately subscribe to the WS. This illustrated user interface screen 
further includes various information related to user reviews of one or more WSes 
(e.g., of a WS selected in another portion of the screen, or of a particular WS 
indicated to the user), including a user-selectable control 148 with which the user 
can select to provide their own review and rating of the WS (e.g., after use of the 
WS) and a section 149 that includes various review and rating information for the 
WS provided by one or more other users. While these various types of WS- 
related information are illustrated on a single screen in this example, in other 
embodiments some or all of the information could be provided at other times and 
in other manners (e.g., by providing review and rating information for a WS on a 
detail screen for that WS, such as the screen illustrated in Figure 1 B). 

[0043] In addition, in some embodiments the user interface may include one or 

more screens that allow the user to specify security and/or privacy information as 
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desired. For example, a WS consumer may be able to prohibit or otherwise 
restrict access to WSes on their behalf (e.g., for all or a specified subset of their 
subscriptions) based on various user-configurable settings, including based on IP 
addresses associated with WSes, on developer tokens associated with users 
making WS access requests, on referring URLs, on subscriber ID, via cookies, 
etc. A WS provider may similarly be able to prohibit or othenvise restrict access 
to WSes that they provide in a variety of ways, and WS providers and WS 
consumers may in some embodiments be able to specify various security and/or 
privacy information for use in accessing information about their accounts and 
provided and/or accessed WSes. 

[0044] Figure 2 is a network diagram illustrating components and information flow 

of an example embodiment of the WSM system and of various external computing 
systems and users interacting with the WSM system. In particular, in the 
illustrated embodiment various WS consumers 210 and WS providers 220 
external to the illustrated WSM system 250 interact with the WSM system to 
register, identify, subscribe to, and obtain access to WSes. In addition, in this 
example embodiment various optional third parties 230 external to the WSM 
system may also interact with the system to receive or provide various enhanced 
or alternative capabilities and functionalities. 

[0045] In particular, WS providers interact with a front-end interface 255 of the 

WSM system to register WSes, as well as in some embodiments to initially 
register themselves as users of the WSM system (e.g., as WS provider users). In 
the illustrated embodiment, the front-end interface 255 may be a Web site with 
which the user interacts and/or an API (e.g., a WS API) with which external 
computing systems and executing applications interact, although in other 
embodiments other types of front-end interfaces may alternatively be used. 

[0046] In this illustrated embodiment, after the front end 255 receives a 

registration request for a WS provider or for a WS available from the provider, 
con-esponding information is fonvarded to an Access Controller component 260 of 
the WSM system to determine whether to approve the request (e.g., based on 
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whether sufficient appropriate information was provided, and/or on whether other 
predefined criteria have been satisfied), and indicates to the front end whether 
the request was approved. In addition, the Access Controller component stores 
information about the registered WS or WS provider for later use in a WS 
database 263 or Consumer/Provider User Account database 261 , respectively. 

[0047] In a similar manner, WS consumers interact with the front end to obtain 

information about available WSes, to subscribe to or otherwise request access to 
available WSes, and in some embodiments to initially register with the WSM as a 
user (e.g., a WS consumer user) prior to such subscription/access requests. As 
with registration requests from WS providers, the front end forwards information 
regarding WS consumer registration, subscription, and access requests to the 
Access Controller for determination of whether to approve the requests, and the 
Access Controller responds to the front end in an appropriate manner. The 
Access Controller also stores information about registered consumers in the 
Account database 261 and about registered subscriptions to WSes and other WS 
access authorizations in the WS subscription database 265. 

[0048] In other embodiments, some or all such information could instead be stored 

in other manners, such as to maintain separate account database information for 
WS consumers and WS providers, or to instead maintain subscription information 
along with other user information in the Account database. In addition, in 
embodiments in which WS providers and/or WS consumers can specify 
notification requests (e.g., at the time of user registration), such information is 
also forwarded to the Access Controller, which stores the infomriation as 
appropriate in the WS Notification Conditions database 267 for later use. 

[0049] In the illustrated embodiment, the WSM system further includes a WSM 

Portal component 290 with which WS consumers and WS providers can interact 
to obtain information about their accounts and to perform other interactions with 
the WSM system, such as to monitor and/or manage WS-related information. In 
some embodiments, the WSM Portal interacts with the front-end interface to 
perform requested retrievals and modifications of information, while in other 
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embodiments instead interacts directly with the various databases 261 , 263, 265, 
267, 277 and 282 as appropriate. 
[0050] When a WS access request is received from a WS consumer and the 

Access Controller approves the request, the front end interacts with a WS Inyoker 
component 270 to perform invocation of one or more WSes as appropriate, such 
as based on information retrieved from the WS database and/or received from the 
front end. The WS Invoker component then interacts with one or more WS 
providers as appropriate to invoke the appropriate WSes and to receive response 
information. In some embodiments, the WS Invoker stores received response 
information in an optional cache 272 for later use, such as to use in lieu of a WS 
invocation in certain situations as appropriate. In addition, in some embodiments 
one or more of the WS providers from which the WS Invoker may invoke WSes 
can be one or more optional internal WSM WS providers 273. After obtaining the 
appropriate response information, whether from a WS provider or from the cache, 
the WS Invoker component returns the response information to the front end. In 
some embodiments, the front-end interface performs additional processing on the 
received response information before providing it to the requesting WS consumer, 
such as to aggregate information from multiple invoked WSes and/or to format the 
response information in accordance with previously specified preferences for the 
WS consumer. 

[0051] In addition, in the illustrated embodiment the WS Invoker component also 

provides information to a WS Transaction Monitor component 275 regarding 
some or all processed WS invocation requests, such as for all requests whether 
satisfied from the cache or from a WS provider, or instead only for successful 
requests to an external WS provider. In the illustrated embodiment, the WS 
Transaction Monitor component in turn stores information about the transactions 
in a WS Transaction database 277 as appropriate. In addition, in the illustrated 
embodiment the WS Transaction Monitor component reviews information in the 
WS Notification Conditions database to determine whether transactions and/or 
other status information have triggered one or more specified notification 
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conditions, such as after each transaction or instead on a periodic basis. When 
the WS Transaction Monitor component determines that one or more notifications 
have been triggered, the component fonvards corresponding information to a 
Customer/Provider Notifier component 279 to perform notifications to WS 
consumers and/or WS providers as appropriate. 

[0052] When a received request by the Access Controller and/or WS Invoker 

corresponds to payment that needs to be obtained (e.g., for subscription requests 
or other WS access requests), one or more of the components interact with a WS 
Payment Module component 280 in the illustrated embodiment to provide 
information about the corresponding request or transaction, although in other 
embodiments the front end could instead interact directly with the Payment 
Module. The Payment Module then determines appropriate payment that is 
needed (e.g., by receiving the information from another component and/or by 
retrieving appropriate information from one or more of the databases, such as the 
WS Subscription database, WS database and/or Account database), and 
performs the necessary functions to obtain the payment, such as in accordance 
with previously provided payment source information and any specified 
preferences. The Payment Module also stores information about the payments 
obtained from WS consumers and any corresponding payments owed to WS 
providers in a WS Payments database 282. 

[0053] As previously noted, in some embodiments one or more third-party systems 

or users 230 may additionally be present to interact with the WSM system, such 
as via the front-end interface. As discussed in greater detail elsewhere, such 
third-party systems may provide a variety of types of services and functionalities, 
including coordination, agent-based monitoring, etc. 

[0054] Figure 3 illustrates a server computing system 300 suitable for executing 

an embodiment of the Web Services Marketplace ("WSM") system facility, as well 
as various WS consumer computing systems 350, WS provider computing 
systems 370, and other computing systems 390. In the illustrated embodiment, 
the server computing system includes a CPU 305, various I/O devices 310, 
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storage 320, and memory 330. The I/O devices include a display 31 1 , a network 
connection 312, a computer-readable media drive 313, and other I/O devices 
315. 

[0055] An embodiment of the WSM system 340 is executing in memory, and it 

interacts with the other computing systems over the network 380 using the 
network connection 312 (e.g., via the Internet and/or the World Wide Web). The 
other computing systems can similarly execute various information as part of the 
interactions, such as a Web browser 359 executing in memory 357 of the WS 
consumer computing systems to allow users of the systems to interact with the 
WSM system, and such as a WS server 379 executing in memory 377 of the WS 
provider computing systems to provide Web service functionality. Such other 
computing systems also include a variety of I/O devices in the illustrated 
embodiment, including network connections to communicate with each other and 
the server computing system over the network. In addition, in the illustrated 
embodiment a variety of datastores (e.g., databases) 321, 323, 325, 327, 328 and 
329 are present on the storage 320 for use by the WSM system, although in other 
embodiments some or all such databases may instead be located elsewhere 
and/or be organized in other manners, 

[0056] Those skilled in the art will appreciate that the illustrated computing 

systems are merely illustrative and are not intended to limit the scope of the 
present invention. Computing system 300 may be connected to other devices that 
are not illustrated, including through one or more networks such as the Internet or 
via the Web. More generally, the "server" and other computing systems may 
comprise any combination of hardware or software that can interact in the 
manners described, including computers, network devices, internet appliances, 
PDAs, wireless phones, pagers, electronic organizers, television-based systems 
and various other consumer products that include inter-communication 
capabilities. In addition, the functionality provided by the WSM system 
components illustrated in Figure 2 may in some embodiments be combined in 
fewer components or distributed in additional components. Similarly, in some 
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embodiments the functionality of some of the illustrated components may not be 
provided and/or other additional functionality may be available. 
[0057] Those skilled in the art will also appreciate that, while various items are 

illustrated as being stored in memory or on storage while being used, these items 
or portions of them can be transferred between memory and other storage 
devices for purposes of memory management and data integrity. Alternatively, in 
other embodiments some or all of the software modules and/or components may 
execute in memory on another device and communicate with the illustrated 
computing device via inter-computer communication. Some or all of the WSM 
system components or data structures may also be stored (e.g., as instructions or 
structured data) on a computer-readable medium, such as a hard disk, a memory, 
a network, or a portable article to be read by an appropriate drive. The WSM 
system components and data structures can also be transmitted as generated 
data signals {e.g., as part of a carrier wave) on a variety of computer-readable 
transmission mediums, including wireless-based and wired/cable-based mediums. 
Accordingly, the present invention may be practiced with other computer system 
configurations. 

[0058] Figure 4 is a flow diagram of an embodiment of the WS Registration 

routine 400. The routine processes requests from WS providers to register WSes 
at the WSM for use by WS consumers. 

[0059] The routine begins at step 405 where an indication is received from a WS 

provider to register a WS. The routine continues in the illustrated embodiment to 
step 410 to determine whether the WS provider is a registered user of the WSM, 
and if not continues to step 415 to attempt to register the WS provider (e.g., by 
obtaining contact information for the WS provider, information about how to 
provide payment to the WS provider based on use of the provider's registered 
WSes by WS consumers, etc.). After step 415, the routine continues to step 420 
to determine whether the registration of the WS provider was successful. If so, or 
if it was instead determined in step 410 that the WS provider was already 
registered as a user (or did not need to be registered as a user), the routine 
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continues to step 425 to receive an indication from the WS provider of various 
information corresponding to the WS being registered, such as a name, one or 
more use prices, a description for use by potential consumers, other non-price 
use conditions, and invocation details for the WS. In some embodiments, such 
information may instead be received as part of step 405. 

[0060] After step 425, the routine continues to step 430 to determine whether to 

accept the WS registration, such as based on an automated determination (e.g., 
on whether appropriate information has been supplied and any predefined criteria 
had been satisfied) and/or a manual determination (e.g., by a user representing 
the WSM based on whether the WS is appropriate for the WSM). In step 435, the 
routine determines whether the registration was accepted, and if not continues to 
step 440 to generate a registration denial message for the WS provider. If it was 
instead determined in step 435 that the registration was accepted, the routine 
continues instead to step 445 to assign a unique item ID to the WS for use by the 
WSM system in tracking various information related to the WS. The routine then 
continues to step 450 to optionally receive one or more of various types of 
information related to the WS, such as any use throttling conditions (e.g., limits on 
how many invocation requests to allow for the service), availability conditions 
(e.g., times at which the WS is not available or other conditions under which the 
WS is available or not available), notification conditions related to the WS, etc. 
The routine then continues to step 455 to store the various received information 
related to the WS in one or more databases as appropriate, and then makes the 
registered WS available to potential consumers in accordance with any 
availability conditions. In step 460, the routine then generates a registration 
acceptance message for the WS provider. 

[0061] After steps 440 or 460, the routine continues to step 465 to send the 

generated message to the WS provider, and optionally provides additional 
information related to the registration (e.g., the assigned item ID). In step 470, the 
routine then determines whether to register more WSes for this WS provider, and 
if so returns to step 425. If not, the routine continues to step 495 to determine 
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whether to continue. If so, or if it was instead determined in step 420 that the WS 
provider registration was not successful, the routine returns to step 405, If the 
routine instead determines not to continue, the routine continues to step 499 and 
ends. While not illustrated here, in some embodiments the routine could 
additionally use various security information and/or mechanisms, such as to 
ensure that only authorized WS providers can register new WSes. In addition, as 
previously described, in some embodiments the routine may be provided as part 
of a user's interaction with a Web site or other interactive interface, while in other 
embodiments the routine may be performed as part of a programmatlcally 
accessed API. 

[0062] Figure 5 is a flow diagram of an embodiment of the WS Subscription 

routine 500. The routine receives requests from WS consumers to subscribe to 
specified WSes, and responds as appropriate. As described in greater detail 
elsewhere, a WS consumer can identify WSes of potential interest in a variety of 
ways prior to selecting one or more of those WSes for subscription. In addition, in 
the illustrated embodiment a WS consumer can both subscribe to WSes for later 
access or instead request immediate access without a subscription, although in 
other embodiments only one of the types of access requests may be provided. 

[0063] The routine begins at step 505 where an indication is received from a WS 

consumer of a WS of interest. The routine continues to step 510 to determine 
whether the WS consumer is a registered user of the WSM system, and if not 
continues to step 515 to attempt to register the WS consumer (e.g., by obtaining 
contact information, payment source information, information about any 
associated applications and/or affiliates if the consumer is a developer of one or 
more application programs, preferences for how to receive information, etc.). The 
routine then continues to step 520 to determine whether the registration of the 
consumer was successful. If so, or if it was instead determined in step 510 that 
the WS consumer was already registered (or that registration of the consumer 
was not needed), the routine continues to step 525 to receive information about a 
WS use request from the WS consumer, although in other embodiments such 
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information may instead have been received in step 505. As an example, the 
WS use request may include an indication of a unique item ID associated with 
the WS, an indication of the type of use request (e.g., a subscription request), 
preference information for how to receive response information from the WS, 
payment information if needed for the WS, a type of intended use of the WS, etc. 

[0064] After step 525, the routine continues to step 530 to determine whether to 

accept the WS use request, such as based on whether the request contains 
sufficient appropriate information, on whether any needed payment can be 
obtained based on the request or other information for the WS consumer, on 
whether the WS consumer and/or request satisfies any other specified use 
conditions for the WS, whether the use request would exceed any throttling 
condition specified for the WS, etc. The routine continues to step 540 if it was 
determined in step 535 that the request was accepted in order to determine 
whether the use request was a subscription request for later use. If so, the 
routine continues to step 545 to generate a subscription ID corresponding to the 
subscription for later use by the WS consumer during access requests 
corresponding to the subscription. In step 550, the routine then retrieves details 
about how the consumer should request the WS and about the format of any 
response information. In step 555, the routine then optionally receives one or 
more of a variety of types of information related to the subscription, such as any 
notification conditions related to the subscription, any application and/or affiliates 
associated with the subscription, any subscription use throttling and/or availability 
conditions (e.g., to restrict it use by affiliates), etc. 

[0065] After step 555, or if it was instead determined in step 540 that the use 

request was a non-subscription request for immediate access, the routine 
continues to step 560 to obtain payment for the subscription or immediate access 
if needed, such as based on any payment source information received or 
previously associated with the WS consumer. After step 560, the routine 
continues to step 565 to determine whether any needed payment was received, 
and if so continues to step 570 to again determine whether the use request was a 
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subscription for later use. If so, the routine continues to step 575 to store any 
received information for the subscription and to send the generated subscription 
ID and the retrieved details about how to request the WS to the WS consumer for 
later use. If it was instead determined in step 570 that the use request was a non- 
subscription request for immediate access, the routine continues to step 580 to 
execute a routine to invoke the Web service to obtain response information as 
appropriate. In step 585, any response information received in step 580 is then 
sent to the WS consumer. 
[0066] After steps 575 or 585, the routine continues to step 595 to determine 

whether to continue, and if not continues to step 599 and ends. If it was instead 
determined in step 595 to continue, or in step 520 that the WS consumer 
registration was not successful, or in step 535 that the WS use request was not 
accepted, or in step 565 that any needed payment was not received, the routine 
returns to step 505. 

[0067] As with the WS registration routine, the illustrated routine can be provided 

in various ways in various embodiments, including as part of an interactive Web 
site with which a WS consumer user interacts and/or as part of a 
programmatically accessed API. In addition, while not illustrated here, in some 
embodiments various security information and/or mechanisms may be used, such 
as to ensure that only authorized WS consumers are allowed to subscribe to 
some or all WSes and/or to perform immediate WS access requests without 
subscriptions. 

[0068] Figure 6 is a flow diagram of an embodiment of a WS Invocation routine 

600. The routine receives access requests for WSes from consumers, and 
responds by providing access to the WSes via invocations of the WSes on behalf 
of the consumers when appropriate, 

[0069] The routine begins at step 605 where a WS access request is received, 

such as based on a previously created subscription. The routine continues to 610 
to determine whether the access request is a subscription-based request (e.g., 
based on whether a subscription ID is received as part of the request) or instead if 
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an indication is received that the access request is for immediate invocation 
without a subscription (e.g., such as based on a message received from the WS 
Subscription routine illustrated in Figure 5 as part of the execution of step 580). 

[0070] If it is determined in step 610 that the WS invocation request is a 

subscription-based request, the routine continues to step 615 to retrieve 
subscription-related information from the received request, such as an indication 
of the subscription ID for the subscription and of the identity of the WS consumer. 
In step 620, the routine then retrieves stored information for the subscription, and 
in step 625 determines whether to approve the request, such as based on 
whether the subscription is valid, whether any current subscription-based 
throttling conditions and/or WS-based throttling conditions are satisfied, whether 
the requesting user is authorized to use the subscription in the requested manner 
(e.g., is an authorized affiliate for the subscription), etc. If it is determined in step 
630 that the request is not approved, the routine continues to step 635 to send an 
error response message to the requester and to store information about the error, 
but otherwise continues to step 640 to determine whether any payment is needed 
for the request, and if so to attempt to obtain the payment (e.g., for purchased 
subscriptions in which an additional per-access charge applies, or for 
subscriptions that a WS consumer has established such that affiliates using the 
subscription provide their own payment for their use). As discussed elsewhere, 
payment can be obtained in various ways in various embodiments, including by 
dynamically purchasing a subscription or other access (e.g., as a credit card 
transaction), via use of previously acquired WSM points, etc. If it is determined in 
step 645 that needed payment is not obtained, the routine continues to step 635. 

[0071] If it is instead determined in step 645 that any needed payment is obtained, 

or in step 610 that the received request was not a subscription-based request, the 
routine continues instead to step 650 to retrieve stored information for the WS 
including information about how to invoke the WS. The routine then continues to 
step 655 to invoke the WS from the WS provider as necessary to obtain response 
information using the retrieved WS invocation information. While not illustrated 
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here, in some embodiments retrieved information may be stored in a cache or 
other storage mechanism, and such cached/stored information may be 
considered for use rather than invoking the WS from a WS provider. In addition, 
in some embodiments step 655 may be performed regardless of the validation 
actions In step 625 as to v\/hether to approve the request and In step 645 whether 
any needed payment was obtained, such as to perform step 655 in parallel with 
such validation steps and to handle any failure of those steps by not providing to 
the requester any response information and/or other benefits resulting from the 
WS invocation. After step 655, the routine continues to step 660 to store a record 
of the WS access transaction. 
[0072] In step 665, the routine then determines if any notification conditions have 

been triggered by the request and/or response, as well as whether any other 
subscription updates are needed (e.g., to update a subscription after the last 
authorized use has been made so that any next attempt to use a subscription 
would fail), and If so the routine proceeds accordingly to provide such notifications 
and/or perform such subscription updates. After step 665, the routine continues 
to step 670 to determine whether response information was successfully received 
from the WS service invocation, and if not continues to 675 to credit any payment 
obtained in step 640 before continuing to step 635 (In other embodiments, 
payment may not be obtained until after successful invocation to prevent such 
payment credits, or instead payment may be retained even if the invocation fails). 
If it is determined in step 670 that response information was successfully 
received, the routine continues to step 680 to format the response information as 
appropriate for the requester (e.g., based on previously specified preferences), 
and then sends the formatted response Information to the requester. After steps 
635 or 680, the routine continues to step 695 to determine whether to continue. If 
so, the routine returns to step 605, and if not the routine continues to step 699 
and ends. 

[0073] As with the registration and subscription routines, the WS Invocation 

routine can be performed in various ways in various embodiments, such as part of 
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an interactive Web site in response to an explicit user request or instead as part 
of a programmatically accessed API. In addition, in some embodiments various 
security information and/or mechanisms may be employed, such as to ensure that 
only authorized WS consumers are able to invoke WSes and that any WS to be 
invoked is from an authorized WS provider. In addition, in some embodiments the 
information provided to a WS consumer about how to request a WS invocation 
and any invocation response information returned to the WS consumer is 
formatted in such a way as to obfuscate or mask various types of information, 
such as the details about how to perform the actual invocation request to the WS 
provider and/or identity or other information about the WS provider — in this way, 
the WSM system is able to ensure that any invocation request to WS providers 
come from the WSM system and are thus authorized. Alternatively, in other 
embodiments, the WSM system may not serve as an intermediary for the 
invocation of some or all WSes, such as by providing to WS consumers the 
details about how to directly interact with a WS provider to invoke a subscribed-to 
or othenvise access-approved WS. For example, in some embodiments, when a 
WS consumer has purchased or otherwise acquired access to a WS, the WSM 
system could provide access authorization information to the consumer to allow 
the consumer to obtain access to the WS directly from the provider of the WS, 
such as details about how to access the WS and/or a token or other indication 
that the WS provider can identify (and optionally verify) as having being supplied 
by the WSM system when the provider receives the information from the WS 
consumer (e.g., a digital signature; information indicating vending payment to the 
WSM, such as transferable WSM points that can be used by the WS provider to 
receive compensation from the WSM system; etc.). 

[0074] Figure 7 is a flow diagram of the WSM Portal routine 700. The routine 

allows WS providers and/or WS consumers to interact with the WSM system to 
monitor WS status and use and to manage registered WSes and subscriptions. 

[0075] The routine begins at step 705, where a request is received from a user. In 

step 710, the routine determines whether the user is authorized to make the 
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request, such as based on security information and associated access privileges 
for the user. If it is determined that the user and request are authorized, the 
routine continues to step 715 to determine whether the request is from a WS 
provider user to modify information for a WS registered by the user, and if so 
continues to step 720 to modify the stored information as appropriate. If it was 
instead determined that the request was not to modify information for a registered 
WS, the routine continues instead to step 725 to determine whether the request 
was to monitor a Web service (e.g., from the Web service provider user that 
registered the WS), and if so continues to step 730 to retrieve information related 
to the WS as requested and provide it to the user (e.g., information about current 
status of the WS and/or usage of the WS). 

[0076] If it was determined that the received request was not to monitor a WS, the 

routine continues instead to step 735 to determine whether the request was from 
a WS consumer user to modify a subscription for the user, and if so continues to 
step 740 to modify the stored information as appropriate. If the request was not to 
modify information for a subscription, the routine continues instead to step 745 to 
determine whether the request is to monitor use of a subscription (e.g., from a WS 
consumer that created the subscription), and if so continues to step 750 to 
retrieve information related to the subscription as requested and provide it to the 
user (e.g., information about use of a subscription by affiliates), 

[0077] If it was instead determined that the request was not to monitor use of a 

subscription, the routine continues to step 755 to determine whether the request 
was to review account information for the user, and if so continue to step 760 to 
retrieve and provide account information to the user as requested. If the request 
was not to review account information, the routine continues instead to step 765 
to perform another requested operation if appropriate, such as to modify the 
user's account (e.g., by purchasing additional WSM points or otherwise providing 
additional payment information). After steps 720, 730, 740, 750, 760 or 765, the 
routine continues to step 795 to determine whether to continue. If so, the routine 
continues to step 705, if not the routine continues to step 799 and ends. 
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[0078] As previously described with respect to other routines, the WSM Portal 

routine can be provided in various ways in various embodiments, including as 
part of an interactive Web site with which the user interacts and/or as part of a 
programmatically accessed API. In addition, various security mechanisms may be 
provided to ensure that users are authorized to obtain the information requested 
and/or to make the requested modifications to information. 

[0079] Those skilled in the art will also appreciate that in some embodiments the 

functionality provided by the routines discussed above may be provided in 
alternative ways, such as being split among more routines or consolidated into 
less routines. Similarly, in some embodiments illustrated routines may provide 
more or less functionality than is described, such as when other illustrated 
routines instead lack or include such functionality respectively, or when the 
amount of functionality that is provided is altered. In addition, while various 
operations may be illustrated as being performed in a particular manner (e.g., in 
serial or in parallel) and/or in a particular order, those skilled in the art will 
appreciate that in other embodiments the operations may be performed in other 
orders and in other manners. Those skilled in the art will also appreciate that the 
data structures discussed above may be structured in different manners, such as 
by having a single data structure split into multiple data structures or by having 
multiple data structures consolidated into a single data structure. Similarly, in 
some embodiments illustrated data structures may store more or less information 
than is described, such as when other illustrated data structures instead lack or 
include such information respectively, or when the amount or types of information 
that is stored is altered. 

[0080] From the foregoing it will be appreciated that, although specific 

embodiments have been described herein for purposes of illustration, various 
modifications may be made without deviating from the spirit and scope of the 
invention. Accordingly, the invention is not limited except as by the appended 
claims and the elements recited therein. In addition, while certain aspects of the 
invention are presented below in certain claim forms, the inventors contemplate 
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the various aspects of the invention in any available claim form. For example, 
while only some aspects of the invention may currently be recited as being 
embodied in a computer-readable medium, other aspects 'may likewise be so 
embodied. 
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